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5 DESCRIPTION 
DOMAINE TECHNIQUE 

f 

La presente invention conceme un procedS 
d'affichage d'un document, par exemple une page HTML 
("Hypertext mark-up language"), sur ion Scran de 
10 visualisation susceptible d'etre soumis a une procedure 
de defilement ("scrolling"), par exemple sur un ecran 
de television numerique. 

*• 

ETAT DE LA TECHNIQUE ANTERIEURE J 

Le domaine de l 1 invention est notamment A 
.15 celui de I'affichage de pages HTML, comme decrit dans v- 
la demande de brevet EP 1 164 499, A j 

Une version de la norme HTML ("HTML 4.01 J$ 
Specification W3C Recommendation 24 dScembre 1999") 
peut etre trouvSe a 1 ' adresse Internet suivante' 

» 

20 http: //www. w3 . org/TR/1999/REC-htmT401-1999 1224 

Une page HTML est un document qui peut etre 
interprets par un programme de lecture pour produire 
une sortie visuelle, et eventue 1 1 ement audio, sur un 
moniteur d'ordinateur ou sur un ecran de television. 

25' Une page HTML presentee sur un Scran est constitute 
habitue 11 ement d'un document principal et de documents 
secondaires pouvant contenir des elements graphiques, 
sonores ou du code source, 

Afin de tenir compte de cette page HTML, 

3 0 ces Elements sont charges, stockes en memoire et 



traites par un raoteur HTML . La representation de cette 
page est stock6e dans une memoire graphigue pour 
af f iehage . 

Un moteur HTML est une application 
interactive permettant de visualiser des documents 
hypertexte et multimedia accessibles au travers du 
reseau Internet. II permet egalement d'envoyer et de 
recevoir du courrier eiectronique et de consulter des 
serveurs dits "news", 

Dans le domaine de la television numerique 
une telle application interactive est pilotee par 
1 'utilisateur au moyen d ! une telecommande ou a l'aide 
d'un clavier infrarouge. L 1 application peut / en effet, 
integrer une interface de substitution permettant §. 
• I'utilisateur d'effectuer toutes les saisies de texte 
ou autres avec seulement la telecommande. L'affichage 
des documents est realise sur l\€cran. 

La recuperation des documents sur le reseau 
Internet s'effectue par 1 1 intermedia ire de requetes sur 
des serveurs particuliers . Dans le domaine de la 
television numerique cette operation peut etre 
asymetrique . En effet , la requete et le document ne 
transitent pas necessairement par le m§me milieu : La 
requete peut etre effectuee par le reseau tel^phonique 
via un modem, et le document revenir soit par 
I'antenne, c'est-a-dire par emission du satellite, soit 
par le modem. L 1 utilisateur peut alors choisir le type 
de retour. 

Le contenu d'une page HTML peut exc€der 
1 1 espace disponible sur le moniteur ou sur l 1 Scran de 
television. Dans ce cas le moniteur ou 1 1 ecran de 



television n'affiche qu'une partie de la page HTML . 
L'utilisateur peut alors faire defiler I'affichage pour 
avoir un apergu des parties restantes de la page HTML. 

Apres defilement:, la nouvelle partie 
visible du document HTML doit etre affichee. Chaque 
element graphique en intersection avec la nouvelle 
partie visible doit etre dessinS ou redessine. 

Le defilement d'un document est couramment 
realist de plusieurs f a<?ons . La manidre la plus simple 
est I'affichage sans preparation prSalable dans une 
m6moire graphique tampon, c'est dire en dessinant 
directement dans la fenStre affichSe a 1 ! Scran. En cas 
de defilement du document, le contenu de la fen§tre\< 
restant toujours visible est deplace par une copie: 
massive & sa nouvelle position dans la fenStre. La- 
bande restante, nouvellement apparue, est affichee en 
redessinant individuellement chaque objet graphique. Ce^ 
procSde a comme inconvenient, lorsque le systeme-'. 
graphique est lent, de voir se composer pr ogres si vement* 
le dessin de chacun des objets graphiques. 

Pour remedier a ce probldme, une solution 
utilisee est de preparer la partie du document a 
afficher dans une memoir e graphique tampon comme par 
exemple un pixmap et- d 1 afficher en une fois le contenu 
de ce pixmap dans la fen§tre visible. Ici deux 
techniques sont utilisees. La premiere consiste a ne 
couvrir par cette memoire tampon que la zone . visible du 
document. Dans ce cas, lorsqu'un defilement est demande 
la nouvelle portion visible du document est prSparee 
dans la memoire tampon et lorsque celle-ci est pr§te, 
elle est affichee (technique appelge "double- 
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buffering"). La seconde consiste a couvrir 
1 1 integrality du document avec une memoire graphique 
tampon, de preparer 1 ■ integrality du document et de 
l'afficher au fur et & mesure des besoins. 
5 Les problemes majeurs de ces deux 

techniques sont que, pour la premiere, l'affichage est 
prepare sur demande explicite de defilement. Par 
consequent, entre la demande et le defilement effect if 
il peut se passer un certain temps d£sagr£able pour 

10 I'utilisateur, le defilement n'etant pas fluide. Pour 
la seconde, si le problSme de temps d'attente n'existe 
pas, elle peut nScessiter une grande quantity de 
memoire graphique puisque celle-ci est li£e a la taille 
de documents. Sur le r^seau internet, la taille des 

15 documents n'est pas limitee et la quantite de memoire 
graphique necessaire pour utiliser cette seconde 
technique peut §tre considerable. 

Une telle solution n'est pas, non plus, 
adaptee I'affichage d l un d^codeur parce que celui-ci 

2 0 necessite une memoire importante pour stocker les 

donnees pixmap qui sont calculees avant l ! affichage. 
Or, la capacite memoire d ! un decodeur de television est 
limitee. Elle est par exemple de l ! ordre de 2 
megaoctets de memoire graphique. Elle est done 
25 nettement plus limitee que celle d'un ordinateur qui 
peut etre de 32 megaoctets, ou 64 megaoctets... 

L 1 invention a pour objectif de resoudre un 
tel probldme, e'est-a-dire d'offrir un defilement 
fluide d f un document dans un contexte de memoire 

3 0 limitee, ce document pouvant par exemple §tre une page 

HTML. 
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EXPOSE DE L' INVENTION 

La presente invention concerne un procSde 
d'affichage d'un document sur un Scran de visualisation 
susceptible d'etre soumis une procedure de' 

5 defilement, caracterise en ce qu'il comprend les €tapes 
suivantes : 

- une etape d 1 attribution au document d'une 
quantite de memoire graphique pour creer une memo ire 
tampon de la partie visible du document et des zones 

10 les plus proches de cette partie visible appelees 
"bandes d 1 anticipation" , 

- une Stape de calcul et de dScoupage en 
pixmaps de cette memoire en fonction de la taille du^ 
document, de la partie visible, et de celles des bandes 5 '* 

15 d 1 anticipation, 

- -une etape, de positionnement relatif de> >: 
ces pixmaps par rapport au document complet et sa£ 
partie visible, £ 

- une etape, realisable en tache de fond,^' 
20 de remplissage du contenu des pixmaps avec un systeme 

de priority en fonction de la proximite du pixmap par 
rapport 3. la zone visible, 

lorsque le document est soumis a une 
procedure d 1 af f ichage * on a un defilement, une etape de 

2 5 recopie du contenu des pixmaps dans la fenetre 

d'affichage avec prealablement si necessaire une etape 
.forgant la mise S jour des pixmaps concernes par 
l ! affichage si 1 1 etape precedente ne I'a pas terminee, 

et retour a 1' etape de positionnement 

3 0 relatif des pixmaps par rapport au document en fonction 

* 

de la nouvelle position de la partie visible. 
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Avantageusement en cas de defilement 
horizontal et vertical, les bandes d 1 anticipation 
coraportent au minimum une colonne de pixmaps a droite 
et & gauche de la fenStre visible ainsi qu'une ligne de 
5 pixmaps en bas et en haut, sauf dans le cas ou la 
fenStre visible approche le bord du document ♦ Les 
pixmaps sont d§coupes en rectangles qui sont dessines 
success ivement & chaque appel d'une tache de fond. 

Le remplissage d'un pixmap s'il est de 
10 grande taille peut §tre long et bloquer le systeme le 
temps de I 1 operation. Le remplissage des pixmaps par 
rectangles de petites tailles permet de diluer 
I 1 operation de remplissage parmi les autres traitements 
du systdme, et pouvoir repondre rapidement a 
15 1 1 utilisateur si n^cessaire. 

La tache de fond a egalement pour fonction 
de construire la zone d 1 anticipation. 

A chaque appel de cette tache de fond, le 
processus est le suivant : 
20 - reorganisation eventuelle des pixmaps si 

un defilement a et§ effectue, 

- s'il n'y a pas eu de repositionnement des 
pixmaps, dessin du premier rectangle d'un pixmap 
determine en fonction d'un critere d' 61oignement de la 
2 5 zone visible du document 

Avantageusement le procede de 1 1 invention 
utilise un m£canisme de synchronisation permettant le 
for<?age 6ventuel des donnees S afficher dans les 
pixmaps . 
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Un dessin imm^diat est realise dans deux 

cas : 

lorsqu'un evenement "expose" oblige a 
dessiner une partie de la fenetre d' aff ichage alors que 
cette partie n'est pas encore dessinSe dans les bandes 
d 1 anticipation, 

- iorsqu'un. element du document est modifi6 
graphiquement dans la fenetre d' aff ichage. 

Le procede de l 1 invention peut Stre 
notamment utilise pour l f aff ichage d f un document HTML, 
et/ou pour un decodeur de television numerique . 

BREVE DESCRIPTION DES DESSINS 

La figure 1 illustre la visualisation de la 
zone d 1 anticipation selon le procede de l 1 invention. 

La figure 2 illustre un exemple de 
d^placement de la zone d ! anticipation. 

La figure 3 illustre le mlcanisme de 
synchronisation , lorsque une partie des pixmaps n'est 
pas retnplie et qu'un aff ichage est demande. 

La figure 4 illustre la constitution d'une 
arborescence de sous -fenet res dans un exemple de mise 
en ceuvre du procede de l r invention. 

La figure 5 illustre l f aff ichage de 
1 1 arborescence representee sur la figure 4. 

Les figures 6 et 7 illustrent, chacune, un 
document HTML apres mise en page selon le procede de 
1 1 invention ; la largeur complete du document pouvant 
§tre couverte avec les pixmaps pour la figure 7, alors 
que pour la figure 6 ce n'est pas possible. 
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EXPOSE DETAILLE DE MODES DE REALISATION PARTICULIERS 

Le procede, selon 1 1 invention, d'affichage 
d'un document, par exeniple une page HTML, sur un Scran 
de visualisation susceptible d'Stre soumis B. une 
procedure de defilement consiste a decouper ce document 
en zones pouvant Stre couvertes par des pixmaps dont la 
taille est fonction de la taille de la zone de 
visualisation, et & prSvoir une zone d f anticipation 
partie du document reellement couverte par des pixmaps. 

Cette zone d 1 anticipation forme une matrice 
de pixmaps, couvrant du document, la partie visible et 
les bandes les plus proches autour de cette partie 
visible, de maniere & preparer le contenu de la partie 
visible et les zones prochainement visibles en cas de 
defilement du document. 

La zone d 1 anticipation a comme finality 
d^mSliorer le rendu visuel des operations de redessin 
d'une partie du document. En effet, dans la plupart des 
cas, une copie de la zone d T anticipation dans la 
fenetre d'affichage s'avdre suffisante. 

La figure 1 represente une telle zone 
d 1 anticipation 10, formSe ici de 18 lignes et 12 
colonnes de pixmaps 13, la fenetre visible 11 oti le 
document 12 est visualise. 

On constate 1 ! inclusion hierarchique des 
trois zones ainsi formees, le document 12 incluant la 
zone d 1 anticipation 10, cette derniere contenant la 
fenetre visible 11 du document. La zone d 1 anticipation 
peut tres bien recouvrir en largeur ou en hauteur le 
document si 1 1 espace disponible est suffisant, comme le 
montre 1 1 illustration de la figure 7. 



La figure 2 montre Involution de la zone 
d 1 anticipation 10 suite a une operation de defilement 
de I'affichage du document 12 vers le bas. Cette 
operation de defilement entraine un deplacement de la 
premiere ligne en has de la zone d 1 anticipation. Cette 

■ 

ligne doit alors etre redessin^e. 

La zone d 1 anticipation comporte au minimum 
une colonne de zones pixmap a droite et §l gauche de la 
fenStre visible ainsi qu'une ligne de zones pixmap en 
bas et en haut, sauf dans le cas ou la fenetre visible 
11 approche le bord du document 12 . Si cette r£gle 
n'est pas respectie & la suite d'un defilement, la zone 
d 1 anticipation se d§place de maniere a retablir celle- 
ci . 

Pour ne pas risquer de bloquer 
1 1 application pendant plusieurs secondes, le dessin de 
la zone d ! antic ipat ion , suite & sa creation ou a un 
defilement, est tel qu'une tache de fond effectue ce 
dessin en plusieurs §tapes : les zones pixmaps sont 
forraees en rectangles qui sont dessines successivement 
a chaque appel de la tache de fond. 

Cette tache de fond a egalement pour 
fonction de construire la zone d 1 anticipation. 

A chaque -appel de cette tache de fond, le 
processus est le suivant : 

- deplacement si necessaire de la zone 
d x anticipation par permutation de lignes ou de colonnes 
en pixmaps, 

- si la zone d ! anticipation est 
correctement posit ionnee, dessin du premier rectangle 
d'un pixmap de la zone d 1 anticipation. 
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Si le pixmap k afficher n'est pas pr§t au 
moment de l'affichage, un mecanisme. de synchronisation 
permet de forcer le raf raichissement des donnees a 
afficher dans les pixmaps. 

Un dessin immediat est realise dans deux 

cas : 

- lorsqu'un ev^nement "expose" oblige h 
dessiner une partie de la fenetre d'affichage alors que 
cette partie n'est pas encore dessin^e dans la zone 
d 1 anticipation, 

- lorsqu'un element du document est modifi£ 
graphiquement dans la fenetre d'affichage. 

Ces deux cas correspondent respectivement a 
un afflux de nouvelles donnees concernant une image et 
au traitement du focus qui modifie le dessin d'un 
element de 1 1 image ♦ 

Dans ces deux cas tous les rectangles en 
attente ayant une intersection commune avec la zone a 
dessiner sont dessinSs. La figure 3 represente les 
elements qui composent alors la zone d 1 anticipation : 

- les rectangles d£j& dessines 2 0 , 

- les rectangles non dessinSs 21 , 

- la fenStre d'affichage 22, 

- le rectangle 23 k dessiner suite a un 
evenement " expose 11 , 

- les rectangles non dessines 24 qui sont 
en interaction avec le rectangle 23, le dessin de leur 
contenu etant forc£ par la synchronisation. 



Mise en oeuvre du proc£d£ de 1 [ invention dans une 
application HTML 

On va, a present, considerer tin exemple de 
mise en oeuvre du procedg de 1" invention, dans une 
application HTML dans un decodeur. 

La premiere op6ration consiste k ripartir 
la memoire graphique utilisable dans une arborescence 
de sous-f enetres (ou "frames" HTML) . 

La quantite de memoire graphique disponible 
pour crier les pixmaps est limitie au niveau du 
decodeur. Pour garantir un bon f onctionnement des 
autres applications fonctionnant en meitie temps que le 
moteur HTML, seule une partie de cette memoire est 
utilisge par le moteur HTML pour creer les zoness 
d ! anticipation. La quantite de memoire disponible ejsfc 
definie au lancement du moteur HTML. Dans le cas ou 
plusieurs documents deroulants sont visible^ 
siraultanement a 1 1 ecran (cas des sous-f enetres ou 
"frames" HTML) , il faut que chaque document puisse 
prof iter du mecanisme de dSroulement fluide que 
constitue le proc£d<S de 1» invention. La quantite de 
memoire disponible doit done §tre ripartie sur tous les 
documents visibles simultanement . 

Le proc6d£ de 1' invention ne concerne que 
des documents deroulants. Les documents declarant des 
sous-f enetres HTML ne peuvent jamais Stre deroulants. 
Seuls les documents feuilles d'une arborescence de 
sous-f enetres sont susceptibles d f §tre deroulants, et 
sont done utilisateurs potentiels du proc£d<§ de 
1' invention. Ainsi, la somme des parties visibles des 
documents HTML susceptible d* 1 Stre diroulante couvre 
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exactement la surface reservee a l'affichage du moteur 
HTML. Cette propriety est utilisee pour garantir une 
utilisation du proceed de 1 ! invention pour chaque 
document feuille. 

5 Le moteur HTML r^partit proportionnellement 

la memoire graphique, en fonction de la surface de 
chaque sous-fenetre : 

- M represente la quantite de memoire 
graphique reservee au moteur HTML, 

10 - Wte & Bta : la taille en pixels de la 

fenetre d'affichage du moteur HTML, 

- Wf & Hf : la taille en pixels d f une sous- 
fenetre quelconque. 

La quantite de mSmoire graphique utili sable 
15 par cette sous-fenStre pour creer ses zones 
d ! anticipation est proportionnelle & la surface : 

Mf « M* (W£*H£) / (Wm*Hm) 

Un exemple d 1 arborescence de sous-fenetre, 
dans laquelle chaque case const itue un document HTML, 
est illustre sur la figure 4 . On a ainsi un document 
racine, par exemple de 600 x 400 pixels, dont decoule 
un document Frame 1, par exemple de 600 x 100 pixels, 
et un document Frame 2, par exemple de 600 x 300 
pixels, dont decoule un document Frame 2-1, par exemple 
25 de 200 x 300 pixels et un document Frame 2-2, par 
exemple de 400 x 300 pixels. 

L'affichage d'une telle arborescence donne 
le rSsultat illustre sur la figure 5. 

Dans un tel exemple .la repartition de la 
memoire graphique peut Stre realisee de la fagon 
suivante, avec, M = 1.920 Koctets : 
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- Document racine (declaration de frames) = 

0 octet 

- "Frame 1" (document f euille) = 480 Koctets 

- "Frame 2" (declaration de "frames") = 0 

octet 

"Frame 2.1" (document f euille) = 480 

■ 

Koctets 

"Frame 2,2" (document feuille)= 960 

Koctets 

L 1 operation suivante est un problSme de 
determination de granularity des pixmaps : pour line 
quant ite de mSmoire graphique disponible pour un 
document il faut determiner quelle est la taille et la 
granularity des pixmaps qui va permettre le bon. 
fonctionnement du systeme. L'objectif est de garantir. 
• au raoins un pas de defilement, d' anticipation du. 
mouvement de part et d' autre de la zone visible, et, : 
d* avoir au mo ins une rangee de pixmaps pouvant £tr,e 
deplacee d'un c6t€ ou de l 1 autre. 

La figure 6 represents un document HTML 12 
complet apr£s la mise en page, la partie couverte par 
les pixmaps 13 et la partie visible 11. Ce document 12 
est susceptible §l la fois d 1 avoir un defilement 
horizontal et un defilement vertical. 

Sur cette figure sont representes les 

parametres suivants : 

* 

- Wd & Hd : largeur et hauteur en pixels du 

document complet apres mise en page, 

- W£ & Hf : largeur et hauteur en pixels de 
la partie visible du document (taille de la sous- 
fen§tre) , 
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- Wp Sc Hp : largeur et hauteur en pixels 

d'un pixmap, 

II existe d'autres parametres non 
representes sur cette figure : 
5 - & Ny : norabre de pixmaps en horizontal 

ou en vertical, 

- Pjc & Py : bande d 1 anticipation garantie 
disponible en horizontal et en vertical de part et 
d' autre de la zone visible (cette bande d' anticipation 

10 correspond, au minimum, au pas de defilement) , 

- T : taille d'un pixel en octets (fonction 
du systeme de codage des couleurs) , 

Mf : quant it e de memo i re graphique 
disponible pour les pixmaps associes au document. 

!5 On considere tout d'abord que le document 

12 peut etre deroule horizontalement et verticalement 
et que la quantite de memoire graphique est 
insuffisante pour couvrir 1 1 integralite de celui-ci 
avec des pixmaps aussi bien en horizontal qu'en 

20 vertical. 

Pour pouvoir garantir & la fois la 
permutation des pixmaps et l 1 existence d'une bande 
d ! anticipation garantie de chaque c6te, on doit 
respecter les inSgalites suivantes : 
25 - 2 Px + Wf < Wp (Mx-D+l (1) 

avec Nx > 1 

- 2 Py + Hf < Hp (Wy-1)+1 (2) 
avec Ny > 1 



30 



15 



La limitation memo ire impose egalement vine 
contrainte. La somme des pixmaps ne doit pas depasser 
la quant ite de memoire reservee ; 

Mf > Nx*Ny*Wp*Hp*T <3) 
Le nombre d 1 Equations est encore 
insuff isant pour determiner le nombre et la taille des • 
pixmaps* Aussi, on opte pour certaines conditions 

particulidres : 

- Px, la zone d 1 anticipation horizontale 

garantie, est definie comme 6gale au pas de defilement 

♦ 

horizontal - 

Py, la zone d f anticipation verticale 
garantie, est definie comme egale au pas de defilement 

vertical . £ 

- Px » Ot Wf : le pas horizontal <de 

* 

defilement est proportionnel & la largeur d'affichage 
du document . 

- Py « <X Hf : le pas vertical de defilement 
est proportionnel & la hauteur d'affichage du document 
avec 0 < <X < 1, (X etant une constante du moteur HTML 
(contrainte garantissant que 1 ! integralite du document 
peut etre consulte par un deroulement pas k pas) . 

[Wp*Nx)*H£ = (Hp*Ny)*Wf (4) : les 
dimensions de la zone d 1 anticipation sont 
proportionnelles aux dimensions de la zone d'affichage. 

On determine la taille et le nombre de 
pixmaps en horizontal en utilisant les Equations (3) et 
(4) et en considerant que la capacite maximum de la 
memoire graphique doit etre utilisee. On obtient le 
r€sultat suivant : 
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W p *Nx = ( (M£*W£) J (H£*T) } 1/2 (5) 
oil Wp*Itfx: correspond a la largeur en pixel de la zone 
d 1 anticipation. 

En utilisant les equations (1) et (5) , on 
5 obtient la largeur maximum d ! un pixmap : 

W pmax = ((Mf*W£)/(Hf*T)) 1/2 +l-(2 (X +l)Wf 

En divisant la largeur de la zone 
d 1 anticipation de (5) par la largeur maximum 

d'un pixmap Wpmax et en arrondissant la valeur enti^re 
10 superieure, on obtient le nombre de zones pixmap 
minimum en largeur Nx min . 

Pour toute les valeur s de Nx > Nxmin, t le 
bon fonctionnement du proc^de de I 1 invention est 
assurg. Dans la mise en oeuvre du moteur HTML, c'est la 

15 valeur Nx m ± B qui est retenue pour le dScoupage. En 
effet, au niveau du dScodeur, le nombre de pixmaps 
pouvant §tre cre6 est limite. On garantit ainsi au 
maximum la possibility d'utiliser le proc^de de 
1 ! invention et on §vite done d l atteindre une telle 

2 0 valeur critique. 

La largeur reelle d ! un pixmap Wp est 
obtenue en divisant la largeur de la zone 
d 1 anticipation (WP#Nx) de (5) par le nombre de pixmaps 
retenu Nx^in arrondi au nombre entier inferieur. 

25 Dans 1 1 exemple de la "Frame 2.2", en 

prenant un coefficient (X a 10% et T = 4 octets, les 
resultats obtenus sont les suivants : 

- Nx m 7 

- Wp = 80 pixels 
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La determination de la taille et du nombre 
de pixmaps en vertical est realis^e de la mSme fa<?on 

qu'en horizontal . 

Dans l'exemple consid^re, les resultats 

5 obtenus pour "Frame 2.2" sont les suivants : 

- Ny = 7 

- Hp m 60 pixels 

Avec cette . mgthode de calcul, la 
granularity des pixmaps est toujours la meme en 
10 horizontal et en vertical. 

Dans la mise en aeuvre du dScodeur, il faut 
tenir compte d'un parametre supplement a ire : les 
pixmaps crees doivent toujours avoir des dimensions 
multiples de 8 pixels. Par consequent, apres ;§voir 
. 15 determine la taille de chaque pixmap et le nombre de 

4 

pixmaps dans une direction, en arrondissant : cette 
taille au multiple de 8 inferieur, on verifier que 
liquation* (1) ou (2) selon la premidre dir^qtion 
traitee) est toujours validSe. Si ce n'est plus le^cas, 
20 il faut augmenter de 1 la granularite des pixmaps et 
recalculer la nouvelle taille d'un pixmap. 

Avec ces arrondis, une partie de la memoire 
reservee pour le calcul dans une direction peut n'Stre 
plus totalement utilisee. Ce trop plein de memoire est 
25 alors report^ sur 1 1 autre direction avant de calculer 
la taille et le nombre de pixmaps. Dans ces nouvelles 
conditions, la granularite horizontale et verticale 
peuvent devenir dif f erente . 

Comme illustre sur la figure 7, dans le cas 
30 ou Wp*Nx > Wd, il est possible de couvrir toute la 
largeur du document avec des pixmaps. Il n'y a done pas 
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besoin d ! un mecanisme de permutation horizontal. La 
determination du norabre et de la granular ite des 
pixmaps est differente. Le trop plein de memoire 
graphique disponible au niveau du defilement horizontal 
est affect^ au defilement vertical. La largeur des 
pixmaps est alors la largeur maximum de creation d f un 
pixmap dans un decodeur. 
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RE VEND I CAT I ONS 



1. Proceed d'affichage d'un document (12) 
sur un ecran de visualisation pouvant etre soumis ..a une 
procedure de defilement, caracterise en ce qu'il 

coraprend les etapes suivantes : 

- une etape d' attribution au document d'une 
quantite de memoire graphique pour crier une memoire 
tampon de la partie visible du document et des zones 
les plus proches de cette partie visible appelees 
bandes d 1 anticipation (10), 

- une etape de calcul et de dScoupage en 
pixmaps de cette memoire en fonction de la taille du 
document, de la partie visible, et de celles des bandes 

d' anticipation- (10) , 

- une etape de positionnement relatif de 
ces pixmaps par rapport au document complet et sa 

partie visible, 

- une 6tape, realisable en ttche de fond, 
de remplissage du contenu des pixmaps avec un systeme 
de priorite en fonction de la proximite du pixmap par 
rapport a la zone visible, 

- lorsque le document est soumis a une 
procedure d'affichage- ou a un defilement, une etape de 
recopie du contenu des pixmaps dans la . fenetre 
d'affichage avec prealablement si necessaire une etape 
forcant la mise a jour des pixmaps concern6s par 
l'affichage si 1* etape precedente ne l'a pas terminee, 

- et retour a 1' etape de positionnement 
relatif des pixmaps par rapport aux documents en 
fonction de la nouvelle position de la partie visible. 
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2. Proced6 selon la revendication 1, dans 
lequel les bandes d f anticipations (10) comportent au 
minimum une colonne de pixmaps a droite et S gauche de 

5 la fenetre visible (11) ainsi qu'une ligne de pixmaps 
en bas et en haut, sauf dans le cas ou la fenetre 
visible (11) approche le bord du document (12) . 

3. Proced6 selon la revendication 1, dans 

10 lequel les pixmaps (13) sont decoupes en rectangles qui 

sont dessin€s successivement a chaque appel d'une tache 
de fond, 

4. Precede selon la revendication 3, dans 
15 lequel la tache de fond a egalement pour fonction de 

. const ruire les bandes d 1 anticipation (10) . 

5. Proc^de selon la revendication 3, dans 
lequel, & chaque appel de cette tache de fond, on a *: 

20 - reorganisation eventuelle des pixmaps si 

un defilement a ete effectue, 

- s'il n T y pas eu de repos i t ionnement des 
pixmaps, dessin du premier rectangle d r un pixmap 
determine en fonction d'un critdre d 1 eloignement de la 

25 zone visible du document. 

6. Procede selon la revendication 1, qui 
utilise un mecanisme de synchronisation permettant le 
for<?age eventuel des donnles a afficher dans les 

3 0 pixmaps. 
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7- Procede selon la revendication 1, dans 
lequel un dessin immediat est realise dans deux cas : 

- lorsqu'un evenement "expose" oblige a 
dessiner une partie de la fenetre d'affichage alors que 
cette partie n'est pas encore dessinee dans les bandes 

d' anticipation (10), 

- ou lorsqu'un element du document est 

modifie graphiquement dans la fenetre d'affichage. 
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8. Utilisation du procede selon l'une 
quelconque des revendications precedentes pour 
l'affichage d'un document HTML. 



9. Utilisation du procede selon l'une 
15 quelconque des . revendications 1 a 7 dans un decodeur de 



television numerique . 
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